home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001392_daemon _Mon Jun 21 18:10:11 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA10521; Mon, 21 Jun 93 18:10:18 MET DST
  3. Return-Path: <dsr@hplb.hpl.hp.com>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA10515; Mon, 21 Jun 93 18:10:11 MET DST
  6. Received: from hplb.hpl.hp.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA16518; Mon, 21 Jun 1993 18:32:30 +0200
  8. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 21 Jun 93 17:24:27 +0100
  9. Received: by manuel.hpl.hp.com
  10.     (16.6/15.6+ISC) id AA14381; Mon, 21 Jun 93 17:30:44 +0100
  11. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  12. Message-Id: <9306211630.AA14381@manuel.hpl.hp.com>
  13. Subject: Re: HyTime compatibility (was Re: HTML spec)
  14. To: C.J.Adie@edinburgh.ac.uk
  15. Date: Mon, 21 Jun 93 17:30:43 BST
  16. Cc: www-talk@nxoc01.cern.ch
  17. Mailer: Elm [revision: 66.36.1.1]
  18.  
  19. Chris,
  20.  
  21. > But a word of caution.  In at least two different places I have read
  22. > that HyTime was designed for the INTERCHANGE of hypermedia data, and
  23. > that it is not necessarily a good choice for an efficient run-time
  24. > hypermedia format.  Of course, it may well be that the overhead
  25. > associated with HyTime is small compared with the network overhead for
  26. > multimedia data transfer - but we should be aware of the problem. 
  27.  
  28. I am still exploring what it means to make HTML+ HyTime compliant
  29. or compatible. It is really a matter of conforming to some of the
  30. architectural ideas in HyTime. We don't need to take on board
  31. everything HyTime includes. In some cases we might want to provide
  32. a HyTime compliant alternative when the normal HTML approach is
  33. incompatible with HyTime. There is no pressure to adopt features
  34. that would penalise an efficient run-time hypermedia format. 
  35.  
  36. At its simplest, we could provide support for hypertext references
  37. via entity declarations following the CLINK and NOTLOC model. This
  38. means you could declare all the references at the start of the
  39. document, and then use local names throughout the body of the
  40. document where ever you need a hypertext reference.
  41.  
  42. With WYSIWYG editors this wouldn't be too much of a pain. The HREF
  43. attribute would remain as now, but there would be an alternative
  44. that assumes local names and which is HyTime compliant.
  45.  
  46. Much of this involves some extra attributes of interest only when
  47. trying to get another HyTime compliant system to make sense of an
  48. HTML+ document. It wouldn't effect HTML+ browsers significantly.
  49.  
  50. Other aspects of HyTime can be included as additions to the DTD as
  51. a bridge to the future when HyTime location ladders and finite
  52. coordinate space elements become useful.
  53.  
  54. Regards,
  55.  
  56. Dave Raggett